perm filename NAUR.LE2[LET,JMC] blob
sn#345028 filedate 1978-03-28 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 .require "let.pub[let,jmc]" source
C00011 ENDMK
C⊗;
.require "let.pub[let,jmc]" source;
∂AIL Dr. Peter Naur↓Begoniavej 20↓DE-2820 GENTOFTE↓DENMARK∞
.<<TEL (01) 65 84 62>>
Dear Peter:
Of course you may use the photographs.
I remember that there was a Paris vote against recursive
procedures, and I was quite disappointed in that outcome, because
LISP experience had convinced me of their value. It was a surprise
to me when the Report was interpreted as admitting them.
I had been someone diffident in advocating them, because I knew that
implementing them in LISP had involved quite different techniques than
were required for FORTRAN implementation, i.e. the use of a stack. In
the event, implementing Algol 60 required entirely new implementation
techniques.
Therefore, I think Baur is correct in what I take to be his
contention that the decision of the Paris meeting was reversed in the
writing of the Report.
While an advocate of recursive procedures, I have mixed
feelings about this outcome. Combined with other mutually incompatible
decisions of the Paris meeting, at which discussions of implementability
were ruled out of order, it confirmed the existing tendency of the
Committee to take no responsibility for the implementability of the
language.
I was involved in advocating four features of ALGOL and
opposing two. I advocated conditional expressions, and I think
their inclusion never gave anyone any difficulty. Recursive procedures
would have given no difficulty in the absence of certain other
features, and they wouldn't have jeopardized non-recursive programs had their
declaration been required as in the American proposal.
My third proposed was the %3own%1 variable. This was devised
at the Paris meeting in an attempt to combine the advantages of the European
block concept with a syntactic block concept that I had developed
and which was implemented in the M.I.T. linking loader for the IBM 704.
The idea of syntactic blocks was to facilitate the combination of
programs written by different people or at different times by
eliminating conflict of symbols. A symbol defined within a syntactic
block had no meaning outside it unless specifically exported or
prefixed by the block name. However, I imagined that compilers would
treat symbols in blocks as symbols with long names, i.e. prefixed by
the string of blocknames (suitably delimited) extending to this block
from the outer level. The European concept of block was a more
semantic notion since it freed the storage occupied by a variable
outside the block. %3own%1 variables were an off-the-cuff attempt
to allow both concepts. No-one imagined dynamic %3own array%1s at
the Paris meeting, and no-one presented even one example of a program
using %3own%1 variables. I must therefore confess a major part
of the responsibility for a thoroughly bad idea.
I waged an unsuccessful battle from the beginning against
numerical labels. In an effort to meet the "need" for computed %3go
to%1s, Turanski and I proposed "designational expressions". A desire to
treat array of labels as ordinary arrays led to the idea that these were
constant arrays and led to oral proposals for constant arrays in general.
(Turanski's death meant that this and perhaps other
ideas with which he had been involved were not adequately presented).
I vaguely recall that numerical labels were supported on the grounds
that full generality required them, and we should always be fully
general. This idea was inconsistently followed in Paris, but much
more consistently in writing the Report.
I opposed the "copy rule" for procedures on the grounds that
we couldn't be sure it led to an efficiently implementable language,
since no-one proposed implementing it by copying, and there was
no assurance that copying wouldn't be required in some cases. The
objection was ruled out of order on the grounds that implementability
shouldn't be discussed.
It seems to me that the Algol 60 Committee, even more than
the Algol 58 Committee, abandoned its original instructions to
develop a standardizable language for numerical computation. Instead,
Algol 60 became a collective research vehicle. Some members, e.g
Perlis, frankly made this their primary objective, and none of us,
as far as I remember, argued directly against it. I don't know
whether the European members had any instructions from the societies
(if any) the represented, but I distinctly recall that John Carr,
then President of ACM, called for a standardizable language or
something like it, in his letter of appointment of the American
members of the Committee.
Ruling discussion of implementability out of order was
another mistake of the Committee. It was assumed that no-one would
propose what he couldn't implement, but this didn't insure that
the combinations were implementable.
My work on the LISP history paper has made me aware of the
fallibility of my memory about long-ago events. Therefore, if these
recollections are completely at variance with what others recall,
ignore them at your discretion, and I won't be offended.
.reg